📜 Description

Fixed issue with non-dismissible keyboard on iOS 26.

💡 Motivation and Context

The problem stems from the fact that we compare 61.66668701171875 vs 61.666666666666664 in old implementation. As a result we were calling UIResponder.reloadInputView too often and during dismissal it caused a keyboard to appear again.

To fix it I added abs(frame.height - desiredHeight) > 0.001 instead of frame.height != desiredHeight. It fixed problem but introduced regression - initial frame had incorrect dimension. It turns out that layoutSubviews wasn't called many times and because of that we didn't specify correct layout. So after creation we need to specify frame. Since we need to do it for modern/legacy views I decided to put common code in default implementation of setupContainerSpecifics and call super.setupContainerSpecifics() from setupContainerSpecifics (in child classes).

Also I wanted to cover this component by e2e tests, but I realized that we can not touch invisible TouchableWithoutFeedback. Then I decided to add button + use KeyboardStickyView, but I discovered too many issues:

• on Android we don't include KeyboardExtender in keyboard rectangle (known issue);
• on iOS 26 after re-attaching extender KeyboardStickyView doesn't change its position (iOS 26 specific bug?)

So taking all these issues into account I decided not to fix all of these issues inside one PR. I'll address them later.

Closes #1207

📢 Changelog

iOS

• use abs(frame.height - desiredHeight) > 0.001 instead of frame.height != desiredHeight;
• use updateContentFrame(desiredHeight: calculateDesiredHeight()) in default implementation of setupContainerSpecifics;
• call super.setupContainerSpecifics() from setupContainerSpecifics (in child classes);

🤔 How Has This Been Tested?

Tested in example app.

📸 Screenshots (if appropriate):

📝 Checklist

• CI successfully passed
• I added new mocks and corresponding unit-tests if library API was changed